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METHOD AND SYSTEM FOR TRANSMITTING MESSAGES ON TELECOMMUNICATIONS 
NETWORK AND RELATED SENDER TERMINAL 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application is the US national phase of PCT 

s application PCT/EP2003/008604 , filed 4 August 2003, published 4 
March 2004 as WO 2004/019583, and claiming the priority of 
Italian patent application TO2002A000724 itself filed 14 August 
2002, whose entire disclosures are herewith incorporated by 
reference . 

10 TECHNICAL FIELD OF THE INVENTION 

The present invention relates to the transmission of 
messages on telecommunication networks. 

BACKGROUND [ [ART] ] OF THE INVENTION 
The introduction of new generation mobile terminals , 
is for instance according to the UMTS standard (Universal Mobile 

Telecommunications System) or the GSM/ GPRS standard (acronyms for 
Global System for Mobile communications and General Packet Radio 
Service) has enabled the transmission and presentation on 
terminal of messages with multimedia content comprising different 
20 elements, such as text, sounds and images, also in motion. 

[[said]] the messages are currently indicated as MMS, acronym for 
Multimedia Messaging System. 

The capability of transmitting [[said]] the messages 
gives rise to different kinds of problems. 
25 In the first place, it is necessary to ensure that 

[[said]] the messages can be constructed with relative ease by 
using an apparatus, like a mobile telephone, which, due to the 
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reduced size and processing capacity, is not ideally suited for 
generating messages with complex content. 

In the second place, it is desirable for terminals with 
the ability to transmit and receive MMS messages to be able to 
s coexist and interact with old generation terminals such as mobile 
terminals operating according to the GSM standard, able to 
generate only text messages of the type currently called SMS, 
acronym for Short Message Service. It is reasonable to think 
that the two technologies are destined to coexist for a fairly 
10 long time before all currently circulating terminals are 
replaced. 

OBJECT DISCLOSURE OF THE INVENTION 
The [ [aim] ] object of the present invention is to favor 
the coexistence and the interaction between terminals with the 
15 ability of transmitting text messages like SMS message and 
terminals able to receive MMS messages. 

SUMMARY OF THE INVENTION 
According to the present invention, said aim this 
object is achieved thanks to a method with the characteristics 
20 specifically set out in the claims that follow below . The 
invention also includes the related system as well as the 
corresponding sender terminal. 

In essence, the solution according to the invention 
allows old generation terminals - able to send SMS text messages 
25 - to induce the generation of messages with multimedia content, 
destined to MMS terminals. 

In the currently preferred embodiment, the solution 
according to the invention allows to provide a service that 
automatically transforms a pure text message into a multimedia 
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message, hence into a "richer" message than the starting message, 
constituted by the pure text. 

In the currently preferred embodiment, the solution 
according to the invention provides for using the system for the 
s automatic automation of three-dimensional characters based on 
text or natural audio produced by the same Applicant and 
identified by the registered trademark JoeXpress®. 

In this regard it is useful to consult the documents 
EP-A-0 991 023 (US 6,532,011) , EP-A-0 993 197 (6,665,643) and 

10 WO-A-01/75805 (7 ,123,262) . The system in question is able to 
transform a text or a recorded voice into the movements of a 
character who enunciates the processed sentences, [[said]] These 
movements also include movements that are not linked with the 
spoken word, with facial expressions and body motions. The 

is system is also able to handle other elements such as the 

personalization of the character's appearance (for example, the 
color of the hair, of the eyes, the way it is dressed, etc.), the 
place where the character is positioned, the movement of the 
viewing point, the background music. All concurs in the 

20 construction of a video clip from a restricted number of input 
parameters provided. 

In this way, the solution according to the invention 
allows, for instance, to generate animations destined to MMS 
terminals on the basis of the text contained in a starting SMS 

25 message. In this case, the result is an MMS message comprising 
different parts, such as the scene description part (in 
"Synchronized Multimedia Integration Language" or SMIL) and the 
parts containing the multimedia objects to be inserted in the 
message, among which are automatically generated animations. 
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The first generation of MMS terminals is subject to 
fairly stringent constraints on message content: in particular, 
video is not supported and the maximum size of the messages is 30 
kBytes . A preferred embodiment of the solution according to the 
s invention therefore allows to incorporate in the generated MMS 
message an animation with small size. In particular, the video 
is transformed into an image according to the GIF standard 
(acronym for Graphics Interchange Format) subjected to animation 
using a rather low animation sampling rate, i.e. around one Hz. 

10 Moreover, the original text is subdivided among the 

various frames of the sequence. By doing so, with animations 
having, for example, sizes in the order of 100x80 pixels (the 
dimensions of the display units of currently marketed MMS 
terminals) one can generate messages containing animations 

is lasting about 15 second, with complex models and scenarios, or 
longer in the case of simpler models, which allow a higher 
compression ratio within the animated GIF image. 

If the total size of the message is limited (for 
instance, to 30 kBytes) making it problematic to transmit both 

20 video and audio, it is possible to cause the terminal, during the 
viewing of the animated GIF image, to reproduce, instead of a 
voice message, a melody inserted in the message: this type of 
sound ("ringer") is able to be contained in a very small number 
of bytes . 

25 In the presence of less strict constraints on the size 

of the message, the solution according to the invention allows to 
transmit, instead of text inside the frames or even in parallel 
therewith, the audio associated with the animation, generated for 
instance by a voice synthesizer. 
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In this scenario, it is possible automatically to 
generate an MMS message even from natural audio, in which case 
the animation is guided by the result of the process carried out 
by a phonetic recognizer. Voice synthesizers and phonetic 
s recognizers able to carry out the functions described above are 
currently available in the art. 

In addition to animation, the MMS message can 
advantageously contemplate a part destined to contain more text, 
melodies and images, useful for inserting, for instance, 
10 so-called "logos" and/or advertising slogans. 

BRIEF DESCRIPTION OF DRAWINGS 

The invention shall now be described purely by way of 
non limiting example with reference to the accompanying drawings, 
in which: [ [-] ] 

is Figure FIG. 1 shows, at functional architecture levels, 

the structure of a system able to operate according to the 

invention , [ [ - ] ] 

Fi g ure FIG. 2 is a flow chart illustrating the steps 

for transmitting a message according to the invention, and - 
20 Fi g ure 3, comprisin g two parts indicated respectively 

as 

FIGS . 3A and 3B , repr o duces show two contiguous parts 
of a functional block diagram illustrating a possible form of 
arrangement of the system according to the invention. 
25 BEST MODE FOR CARRYING OUT THE INVENTION 

The description provided herein refers to the 
application scenario which, at least at present is the most 
attractive one for the possible use of the invention, i.e. the 
conversion of text messages generated as SMS messages in a GSM 
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mobile terminal into MMS messages destined to be transmitted on a 
network operating according to the UMTS standard. 

In any case, the solution according to the invention is 
also applicable to text messages generated differently, for 
s instance in the form of email messages, and it can be used to 

transmit MMS messages on any type of network such as to support 
such a transmission, hence without limitation to UMTS networks. 

In the diagram of Fi g ure FIG. 1 , the numeric reference 
10 globally indicates a module having the function of MMS 

10 relay/server and comprising for this purpose a sub-module with 
relay function, indicated as 101, and a sub-module with server 
function, indicated as 102, mutually connected through an 
interface indicated as 103. Naturally, the sub-modules 102 and 
103 can also be mutually integrated. 

is The numeric reference 11 instead indicates a database 

of the users of an MMS service. This is substantially a database 
where, for each user to whom the MMS service is made available, 
the telephone number (or an equivalent indication) and the 
information about the terminal type employed by the user in 

20 question are recorded. 

The database 11 is connected to the module 10 through 
an interface 111. 

The numeric references 12 and 13 indicate two users 
connected in a network to the module 10 (this can typically take 

25 place through an UMTS network) so as to be able to receive MMS 
messages . 

The user indicated as 12 is a user directly included in 
the network whereto the module 10 is attached. The related 
connection therefore is of the direct type, through an interface 
30 indicated as 121. 
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The user indicated as 13, instead, is a user nominally 
attached to another mobile network. 

In this case, the connection to the module 10 is not 
direct but is achieved through an additional module 10 ' 
s substantially similar to the module 10, by means of corresponding 
interfaces indicated as 131a and 131b. 

The distinct representation of the user 12 and of the 
user 13 is destined to highlight the possibility of applying the 
solution according to the invention also in a context in which 
10 multiple telecommunication networks mutually co-operate in a 
general internetworking or roaming scenario. 

The reference 14 indicates a server, such as an 
electronic mail server, connected to the module 10 through a 
respective interface 141 in order to be able to operate as a 
is recipient of MMS messages. 

Lastly, the reference 15 indicates the system for 
billing the rendering of the MMS message services, connected to 
the module 10 through a respective interface 151. 

The system architecture and the various constitutive 
20 elements described heretofore correspond to solutions to be 

considered wholly known in the art. These solutions are already 
able to be used for sending MMS messages within 

telecommunications networks (such new generation mobile networks 
operating according to the UMTS standard) . This fact makes it 

25 superfluous to provide herein a more detailed description of the 
architecture and of the elements in question. 

An important characteristic of the solution according 
to the invention is given by the fact that to the module 10 it is 
associated, preferably through a respective interface 161, a 

30 module or sub-system 16 able to convert text-only messages, such 
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as SMS messages coming from an SMS message management center 17 
(usually called with the acronym SMSC) into messages with 
multimedia content. After possible further processing in module 
10, [[said]] the messages can be broadcast by the module 10 in 
s the form of MMS messages destined to users such as the users 
12,13 and 14 indicated in Fi g ure FIG. 1. 

In particular, the module 10 can be configured in such 
a way as to allow the transmission of a determined message MMS to 
multiple recipients or to a list of recipients . 
10 Consequently, though hereinafter reference shall be 

made nearly exclusively to the generation, from an SMS message, 
of an MMS message sent to a single recipient, the solution 
according to the invention is easily suited to allow the MMS 
message in question to be broadcast to a list of recipients 
15 defined for instance by means of an http request or by means of 
an ftp request sent to the module 10. 

As stated previously, the core of the module 16 is 
constituted by the system for the creation of multimedia content 
represented by virtual characters animated by text or natural 
20 voice. An example of such a system is the JoeXpress® system, 
mentioned above. 

Such a system enables a user to select a virtual 
character, its background, any personalizations, the format in 
which the content is to be produced. The selected parameters are 
25 used to produce animations with the desired context and format. 

The flowchart of Fi g ure FIG. 2 shows the steps of the 
process whereby a system according to the invention is accessed 
by a user, indicated as 18 in Figure FIG. 1, who acts as a 
"sender." The user 18 has a terminal able to send SMS messages 
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to a corresponding center able to handle this type of messages, 
such as the center indicated as 17 in Figure FIG. 1 . 

Starting from an initial step, indicated as 200, the 
reference 202 indicates the step in which the user 18 composes on 
s his/her terminal an SMS message (with the characteristics better 
illustrated hereafter) sending it to a telephone number 
associated with the service which forwards [[said]] the SMS 
message after providing it with MMS characteristics. 

The service in question is implemented mainly by the 

10 module indicated as 16, but some functi o nalities functions can be 
performed by the module 10 and, possibly, by the module 17. 

In the step indicated as 204 in Figure FIG. 2, the 
service management function-hence essentially the module 16- 
generates the request for the emission of an MMS message 

is corresponding to the received SMS message. As will be explained 
better hereafter, such a request contains, in addition to the 
message itself, also the user's identifier and (possibly) 
information pertaining to the type of recipient terminal . 

In the step indicated as 206, the module 16 processes 

20 the request received, generating an MMS message adapted to the 

graphic and processing capacity characteristics of the recipient 
terminal. In the step indicated as 208, [[said]] the MMS message 
is sent to a corresponding MMS center (such as the module 10) 
which, in a subsequent step 208, forwards the message to the 

25 recipient terminal, such as the terminal 12,13 or 14. 

The step 210 indicates the step in which [[said]] the 
message is presented to the recipient terminal according to the 
typical modes of presentation of an MMS. Once the transmission 
is completed with the reading of the MMS message, the system 

30 moves to a conclusive step, indicated as 212. 
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The telephone number associated with the service, 
destined to be dialed by the user 18 in the step 202 is 
preferably a dedicated telephone number of the kind usually 
called "large account." 
s The sequence of characters sent by the user contains, 

in addition to the text of the message, also some information in 
the header such as the telephone number of the recipient of the 
MMS message (users 12,13, 14 of the diagram of Figure FIG. 1) , 
the virtual character that will reproduce the message and the 
10 background into which it will be inserted. 

The last two information items are optional and can 
therefore be omitted. In case of omission, corresponding 
information are selected automatically by the module 16, for 
instance as a random choice or as a predefined choice (default) . 
is Naturally, this can be applied even for only part of [[said]] the 
information: for instance, if only the character is specified, 
the module 16 automatically selects the background. 

The sequence of characters sent to the service 
therefore usually has the following form: 
20 <recipient telephone number> [<virtual character 

[<background>] ] 
<text message> 

In the step 202 the header of the message can be 
composed either manually or by means of a script residing on the 
25 terminal 18 which allows to select the virtual character and the 
background by means of a menu and the recipient from the address 
book. 

If the message is dialed manually, the sequence of 
characters can contain errors. For example, the user could 
30 specify the name of a non-existing virtual character or 
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background. In this case, the service replaces the faulty 
information by automatically selecting correct options . 

It will be appreciated that [[said]] the script 
functions correspond essentially to functions provided in some 
s mobile telephony terminals for sending SMS messages, with the 
possibility to load the related software remotely in the 
individual terminal 18 (in particular in the Subscriber Identity 
Module or SIM of the terminal) by the same service management 
system. 

10 The module for transforming the SMS text format into 

MMS multimedia format, preferably based on the JoeXpress® systems 
already mentioned several times above, is preferably used in the 
mode called "text animation." 

In this case, the text of the SMS message is processed 

is by a voice synthesizer which transforms the text into voice and 
provides the timed phonetic sequence, which is then used for the 
automatic generation of the speech movements of the selected 
virtual character. The text provided as an input to the SMS /MMS 
conversion module may contain meta-inf ormation that have an 

20 influence over the resulting animation, adding expressions and 
gestures to the virtual characters and altering the synthetic 
voice . 

[ [Said] ] The meta-inf ormation [ [are] ] is inserted in 
the text as sequences of characters that can have, for instance, 
25 the following form: 

<tagXaction_type>[<parl>] [<par2>] . . . [<parn>] 
where : 

<tag> is necessary to distinguish the meta-inf ormation 
from the text to be synthesized 
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<action-type> specifies which action is to be executed. 
Examples of actions are: change in voice timbre, reproduction of 
a facial expression or of a body movement, change in viewpoint, 
etc. 

s <parl-n> is the parameter that modifies the action, for 

instance the alteration of the duration of a facial expression. 

An alternative representation at higher level is 
constituted by the so-called "emoticons," i.e. by sequences of 
characters commonly used in Internet in text communications , 
10 which represent emotional states. Examples of emoticons are : " 
;-)", " :-)", " :-0", etc. 

Emoticons are transformed by the system into a 
semantically equivalent form using the representation described 
above. Support [[to]] for the emoticons is motivated by the fact 
is that they are familiar to users and simple to insert in the text, 
while having the same flexibility as low^level representation. 

A system like the JoeXpress® system produces animations 
of three-dimensional models that can be translated by the system 
into different formats, classifiable in two categories depending 
20 on whether the three-dimensional information is retained or not. 

To the first category belong, for instance, the 
sequences of MPEG- 4 Face and Body Animation parameters, VRML 
animations (acronym for Virtual Reality Modeling Language) , 3D 
Studio Max animations etc. 
25 To the second category belong the video coding formats 

like MPEG-1, MPEG-2, MPEG-4 video, animated GIF (while it is not 
a video coding format in the strict sense of the term, the 
GIF- 8 9a format does allow to create image sequences) . 

The audio of the animation can be encoded together with 
30 the video or separately as in the case of VRML or animated GIF. 
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Due to the limits in the terminals of the transmission 
network, multimedia contents are subject to constraints such as 
the maximum size of the message, spatial resolution, time 
resolution, and the type of coding of the animation, 
s For this reason, in addition to the text of the message 

and to the identifier of the sender, it is necessary to take into 
account the type of terminal whereto the multimedia message is to 
be transferred. 

The terminal type essentially identifies the class of 
10 the terminal (in essence, characteristics such as storage <BR> 

<BR> capacity, display size, etc.) and any other constraints due 
to the transmission network. 

The MMS message destined to be produced in a system 
according to the invention is therefore conditioned to exploit 
is the available resources most efficiently, within the imposed 
constraints . 

This requirement can be met in at least two different 

ways . 

A first way provides for the request to create the MMS 
20 message, generated at step 204, to contain, in addition to the 

text of the message and the sender's identifier, also information 
indicating the class whereto the message to be generated must 
belong, i.e. the type of terminal whereto the MMS message is 
destined and hence its performance characteristics. The video 
25 content destined to integrate the SMS textual message is then 

generated according to the recipient terminal type, i.e. in such 
a way as to cause the MMS message (derived from the multimedia 
message obtained by integrating [[said]] the video content and 
the SMS message) to be directly compatible with the 
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characteristics of the MMS terminal destined to receive the 
multimedia message. 

When this solution is adopted, the module 16 is able to 
search, based on the recipient's identifier, the terminal type 
s information stored in the database 11. The connection between 

the module 16 and the database 11 can be either of the direct or 
of the indirect type, through the module 10, according to the 
criteria whereto Fi g ure FIG. 1 refers . 

A second way to obtain the same result provides for the 
10 multimedia video content (destined to be added to the SMS 
message) to be generated by the module 16 on the basis of 
criteria that are standard, hence independent from the type of 
terminal whereto the message is destined to be transmitted. 

The multimedia message deriving from the integration 
is between the SMS textual message and [[said]] the standard 

multimedia video content is forwarded by the module 16 to the 
module 10 which, reading the information about the recipient 
terminal from the database 11, "specializes" the MMS message 
derived from the multimedia message, adapting it to the 
20 characteristics of the recipient terminal. 

The choice to adopt one or the other solution is 
primarily dictated by application considerations . 

The first solution has, at least in principle, the 
advantage of not entailing the generation of information destined 
25 to be discarded when the message is adapted to the requirements 
of the recipient terminal. However, this advantage is offset by 
the need to ensure that the module 16 is able to receive the 
information about the type of terminal, residing in the database 
11. 
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The second solution has the advantage that it exploits 
the availability of the information of the database 11 at the 
level of the module 10, already normally provided for current MMS 
applications. In current MMS applications, the module 10 is 
s already capable of achieving a specialization of the forwarded 
MMS messages according to the characteristics of the recipient 
terminal. The advantages indicated above, however, are at least 
marginally tempered by the fact that this solution entails the 
generation, by the module 16, of information destined to be 
10 discarded. 

Whichever solution is adopted, it is possible to 
benefit from the fact that the same animation can be represented 
in an MMS message in substantially different manners. 

For instance, one can make use, as stated previously, 

15 of an animated GIF image with a low number of frames per second, 
in which case each frame shows the text of the message pronounced 
at that instant by the character. This particularly compact 
representation is well suited for situations in which the message 
size constraints are particularly stringent, or when the 

20 recipient terminal is not able to show a video. 

Alternatively, one can employ an animated GIF image, 
with compressed audio. In this case, the synthesized voice, 
possibly complete with scene audio, is also included in the 
message. This is a useful representation for terminals that do 

25 not support video but are able to handle audio, when the size of 
the message is sufficiently large to contain both the moving 
image and the audio track. 

An additional alternative is represented by a video 
clip complete with audio. In this case, an animation is obtained 

30 that can be more fluid in its motions thanks to the higher 
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compression ratio offered by a video coding with respect to an 
animated GIF image and to the higher number of frames 
consequently used in the animation. This solution can be adopted 
with terminals that are able to support video coding, 
s It should be stressed that the ways to package the 

message recalled above are mere examples, and they are far from 
being exhaustive of the possibilities offered by the solution 
according to the invention. 

The description will now be provided, with reference to 

10 Figures FIGS . 3A and 3B, of a possible architectural arrangement 
of the module indicated as 16 in Figure 1. 

The block or module 300 is destined to receive as its 
input the SMS message substantially as transmitted by the 
terminal 18 and to perform thereon the operation of extracting 

is the information from the header. 

As previously seen, the first part of the text is 
represented by a header containing the number of the recipient 
terminal (for instance, with reference to the diagram of Figure 
1, the terminal 12, the terminal 13 or the terminal 14) and, 

20 optionally, the indication of the character and of the background 
which the sender user wants to use to generate the video content. 
These data are divided from the actual message by a separator 
character . 

The message can contain low or high-level 
25 me ta- information (for instance the so-called emoticons) which 
influence the resulting animation. 

As an example of such text, one can consider the 

string: 

"3356121180 Morpheus Country@Hi! I'm at the beach:-) 
30 but I'm getting bored without you. \kyawn, 150." 
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In the example, the separator used is the character - 
Associated [[to]] with the message in question are the identifier 
of the sender as well as, possibly, the string indicating the 
recipient ' s terminal model . 
s The reference 302 indicates the database of the module 

16 which, in the preferred implementation based on the JoeXpress® 
system, contains information such as the list of characters 
usable for generating the video content, the languages associated 
[[to]] with them, the available scenarios, etc. The database 302 
10 also contains the three-dimensional models of the characters and 
of the backgrounds . 

Co-operating with the database 302, the block 300 
extracts from the message header information such as the 
recipient's identifier, as well as the character and the 
is background to be used to create the video content. 

The block 300 then communicates with the database 302 
that contains the character list, voices, available backgrounds 
and, if these information are omitted or erroneous in the header 
of the received SMS message, the block 300 automatically selects 
20 correct options . 

The block 300 generates at its outputs the following 
data/information : [ [ - ] ] 

the text of the message without the header ("Hi ! I'm 
at the beach :-) but I'm getting bored without you. \ kyawn, 
25 150") destined to be sent to an additional block 302 whose 

function shall become more readily apparent hereafter; [[-]] 

the name of the character P, protagonist of the 
animation (in the example illustrated herein, [[said]] the name 
is "Morpheus"), [[-]] 
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the language L associated with the character (for 
instance, English), [[-]] 

the background A corresponding to the scenario in which 
the virtual character P is to be placed (in the example 
s considered herein, the background is a "country" background) , and 
[[-]] 

the identifier of the recipient D (constituted, in the 
illustrated example, by the number 3356121180) . 

Starting from the text of the message M received from 
10 the block 300, the block 302 transforms the emoticons into 

me ta- information capable of being used by the information system 
that simultaneously determines what text will be inserted in the 
frames constituting the animation of the MMS message constituting 
the output of the module 16. 
is Therefore, the output of the block 302 is constituted 

both by a text TBS with low-level information, i.e. a text in 
which emoticons are replaced with low-level meta- information 
(""Hi! I'm at the beach \ksmile but I'm getting bored without 
you. \ kyawn, 150") , and a text TE in which all low-level 
20 information has been eliminated, retaining only what will be 

[[said]] the by the character plus the emoticons ("Hi ! I'm at 
the beach :-) but I'm getting bored without you.") . 

The text TBS generated by the block 302 is sent to a 
block 304 destined to extract the list of actions contained in 
25 the text and to prepare the text in the form used by a voice 

synthesizer 306 in such a way as to obtain also the timing to be 
associated [[to]] with the aforesaid these actions. 

The block 304 transmits to the synthesizer 306 a text 
TAG in which the low-level meta-inf ormation are replaced with 
30 "tags" of the voice synthesizer ( text- to- speech) . [[Said]] These 
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tags are sequences of characters identified by the synthesizer as 
special information and used either to alter the synthesized 
voice or to obtain from the synthesizer 306 the time instants 
associated [[to]] with the tags in the synthesized sentence, 
s [[said]] the time instants are used to determine the timing of 
the actions . 

The block 304 also generates as an additional output a 
signal TA substantially corresponding to a list of the actions 
contained in the text, complete with any parameters. 
10 Referring to the SMS message mentioned several times 

above, there are essentially two actions contained, i.e.: [[-]] 

smile, and [[-]] 

yawn, 150. 

The parameter 150 modifies the duration of the "yawn" 
is action with respect to a standard duration. 

The voice synthesizer 306 transforms into a voice 
signal the text TAG received from the block 304 using the 
selected language identified by the signal L generated by the 
block 300. 

20 In addition to the voice signal, the block 306 also 

produces the timed phonetic sequence FT, used as the basis of the 
construction of the movement of the spoken word. It should be 
recalled that the timed phonetic sequence is the sequence of 
phonemes constituting the spoken sentence, integrated with the 

25 time instances whereat the phonemes are spoken. 

The signal indicated as V is, instead, the actual 
synthesized voice signal . 

The blocks indicated with the references 308 and 310 
are engines that supervise the animation of the spoken word and 
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the corresponding facial and body animation of the character used 
for the video content. 

The block 308 receives as an input the phonetic 
sequence FT transforming it into a "visemic" sequence, i.e. into 
s the movement produced by the face as it speaks . 

To obtain a realistic movement, the animation engine 
considers the mutual influence effect of adjacent phonemes, 
[[said]] the co-articulation phenomenon. The movement produced 
is three-dimensional and the related output signal AP is 
10 constituted by animation parameters that describe the movement of 
the spoken word in three- dimensional fashion and independently 
from the character. 

This means that such parameters are successively 
applicable to characters with any shape and complexity, human and 
is otherwise. 

The block 310, serving as facial and body animation 
engine operates on the basis of the list of actions corresponding 
to the signal TA generated by the block 304 integrated in a 
virtual summation node 312 with the information on the timing of 
20 the actions, generated by the synthesizer 306. 

The block 310 operates in co-ordinated fashion with an 
additional database 314 which contains sequences of facial and 
body movements in the form of animation parameters independent 
from the character, thus similar in this regard to the parameters 
25 output by the block 308. In the example, the sequences "smile" 
and "yawn" are two movements drawn from the database 314 . 

The facial and body 310 animation block unites the 
individual actions corresponding to the various movements that 
the character will have to perform, creating a single sequence of 
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animation parameters . The individual movements are altered based 
on any parameters associated therewith. 

The movements also undergo automatic variations in 
intensity, duration, specular characteristics, etc. to enhance 
s variety. Lastly, some movements executed by the characters but 
not explicitly indicated, such as blinking eyelids, are also 
added . 

The output of the block 310 is constituted by a signal 
AFC representative of animation parameters that describe the 

10 movement of the spoken word in three-dimensional fashion, 

independently from the character. [[said]] the parameters are, 
therefore, successively applicable to characters with any shape 
and complexity, human and otherwise, such as animals. 

A successive block indicated as 316 has the task of 

is mixing the movements of the spoken word (signal AP) with the 

other movements (signal AFC) to obtain a realistic result. The 
operation of the block 316 is based on a logic that takes into 
account the priorities of movements that may be contrasting, such 
as speaking a plosive phoneme (such as the letter "p") and 

20 yawning. The resulting movement is three-dimensional. 

The output signal of the block 316 is constituted by a 
signal AIP representative of an animation independent from the 
character . 

The signal AIP is fed to a block 318 that transforms 
25 the independent animation (signal AIP) into the movement of the 
character selected on the basis of the signal P extracted from 
the block 300. The resulting movement is dependent on the 
topology of the model. The model associated with the character 
is, as seen previously, contained in the database 302. 
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The output signal of the block 318 is constituted by a 
signal ADP identifying the sequence of movements of the selected 
character . 

The signal ADP in question is fed to a block 320 that 
s merges the signal ADP with the background information A that 
comes from the block 300 with additional information on the 
characters and on the backgrounds drawn directly from the 
database 302 . 

All this in order to add to the animation of the 
10 character also the remaining animations which may be present in 
the scene (signal A) and can be driven by means of the 
me ta- information in the text, as movement of objects or change of 
the viewpoint of the shot. 

The output signal of the block 320 is constituted by a 
is final three-dimensional animation signal TRD destined to be sent 
to a block 322 tasked with the rendering operation, i.e. with the 
operation of representing on a screen, as a pixel matrix, the 
three-dimensional scene constituted by the character and by the 
background. The sequence of [[said]] the pixel matrix, obtained 
20 at regular time intervals, constitutes the output of [[said]] the 
block. The output of the rendering block 322 is constituted by a 
sequence of video frames of the animation indicated as FV. 

The sampling rate of the video frames is a parameter 
that is typically set in preferred fashion to 25 Hz. 
25 The signal FV is fed as an input to an additional block 

324 destined to receive also the text with emoticons TE generated 
by the block 302. 

The block 324 distributes the text among the various 
frames constituting the video animation produced. [[said]] the 
30 operation is optional and is performed when an MMS message 
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without audio is to be generated, i.e. an MMS message in which 
the SMS message is shown in the form of text and animation. 

The output of the block 324 is constituted by the set 
of all movements of the character and of the scene. [[said]] the 
s signal FVT, corresponding in practice to the sequence of the 

video frames with the text, is fed to a video coding block 326 
destined to receive as its input, in addition to the signal FVT, 
also the signal V pertaining to the synthesized voice as well as 
the information TV pertaining to the type of terminal of the 
10 recipient. 

The embodiment shown in Figures FIGS . 3A and 3B refers 
to a solution in which [[said]] the information is made available 
at the level of the module 16. [[said]] the information 
generally indicates brand and model name of the recipient 
is terminal (for example, Sony Ericsson T68i, Nokia 7650, etc.). 

The block 326 proceeds in this case by creating the 
video clip directly in a format suitable to be viewed from the 
recipient terminal in question. The adaptation of the video clip 
to a determined type of terminal can influence, for example, on 
20 the spatial and time resolution of the frames, on whether the 
audio channel is inserted or not, etc. 

The solution whereto reference is made herein therefore 
provides for integrating the SMS message with a video content 
generated in this way so that the resulting multimedia message, 
25 generated by the module 16, is in a format suitable for being 
viewed from [[said]] the terminal. 

As stated previously, the solution according to the 
invention can, however, also be implemented in conditions in 
which the module 16 (and, therefore, the block 326, in the 
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embodiment illustrated herein) does not carry out any 
"specialization" action of this kind. 

In this case, the video clip, or in general the video 
content destined to complement the incoming SMS text message, is 
s generated in a standard format, i.e. without taking into account 
the characteristics of the recipient terminal. 

The related format conversion, destined to make the 
final MMS message actually viewable by the recipient terminal, is 
then left to the module 10 (Figure 1) with MMS relay/server 
10 functions . 

In the embodiment example illustrated herein (which is 
in fact an example) the output signal from the block 326 is then 
constituted by a signal VC essentially similar to a video clip in 
compressed format, 
is [ [Said] ] [ [The] ] signal is transmitted to a block 328 

destined to construct, starting from the multimedia message 
carried at its input, a message corresponding to the MMS 
standard. 

To proceed in this way, the block 328 receives at its 
20 input, in addition to the signal VC output by the block 326, also 
the signal TE corresponding to the text with emoticon generated 
by the block 302 , the signal pertaining to the recipient D coming 
from the block 300, as well as the information about the sender 
S: the latter information is derived from the center 17 of Figure 
25 1 according to known criteria, requiring no detailed description 
herein . 

To generate the MMS message, destined to be sent to the 
module 10, the block 328 inserts the video animation previously 
computed in an MMS message. This preferably takes place using 
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the SMIL language of description of the scene and joining various 
multimedia objects in a single form comprising multiple parts. 

The block 328 also inserts in the message header the 
information about the sender, recipient and subject. The subject 
s is constructed automatically using the first characters 
constituting the text with emoticons . 

Preferably, the block 328 is also destined to co- 
operate with an additional database 330 constituted by a 
collection of images to be inserted in the MMS message as 

10 "logos" or advertising, or as sounds able to be used as 

background music for the scene or as advertising jingles. 

Naturally, without changing the principle of the 
invention, the details of its implementation and the embodiments 
may be amply varied with respect to what is described and 

is illustrated herein purely by way of example, without thereby 

departing from the scope of the present invention. This holds 
true in particular, but not exclusively, for the possibility of 
applying the invention to convert into MMS messages text messages 
generated other than by an SMS, for instance in the form of 

20 e-mail messages, and to the possibility of applying the invention 
to the transmission of MMS messages on other than UMTS networks. 
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